又一家知名公司删了生产数据库

（点击上方公众号，可快速关注）

【伯乐在线/技术最前线导读】：今年2月4日，GitLab 发生了一次严重删库事故。昨日在 Reddit 上又有一个重磅热帖。原来在 4 月 5 日知名的 VPS 服务商 DigitalOcean 出现了一次删除生产数据库的事故。

删库导致 DigitalOcean 的控制面板和 API 无法正常使用，时间长达 4 小时 56 分。DigitalOcean 官博撰文致歉，并说明了事故前后过程。

我们深知您依赖我们的服务，类似这样的服务中断事故，让人无法接受。我们道歉并承担所有责任。您对我们的信任，是我们最重要的资产，所以我们公开此次事故的所有细节。

DigitalOcean 文章称，在事故期间，所以在运行的 Droplet 功能正常，但无法新建或管理其他 Droplet 或资源。（伯乐在线补注：DigitalOcean 给自家的虚拟主机服务（VPS）取名 Droplet。DigitalOcean 字面意思「数字海洋」，Droplet 字面意思「水滴」，取名非常形象到位。）下面是伯乐在线/技术最前线摘编的 DO 官博文章。

------

在 2017 年 4 月 5 日 10:24 AM EDT，我们开始收到公共服务功能失效的警报。在警报最初的 3 分钟，我们发现主数据库已经被删除了。4 分钟后，我们开始从一台有延迟的数据库副本着手恢复。在接下来的 4 个小时中，我们复制并把数据恢复到主备副本。服务中断这么长时间，主要是因为从副本把数据恢复到在线服务器这个过程非常耗时。

在 3:20 PM EDT，主数据库完全恢复，无数据丢失。

事故时间线

• T0.00 - 10:24 EDT - 收到警报；

• T0.03 - 10:27 EDT - 确认主服务器上的生产数据库被删除了；

• T0.10 - 10:34 EDT - 开始从有延迟的数据库副本恢复数据；

• T1.29 - 11:53 EDT - 有延迟的副本数据完成备份；

• T2.10 - 12:34 EDT - 从备份数据向主数据库的复制工作完成；开始恢复；

• T3.07 - 13:31 EDT - 主数据库完成恢复；

• T4.56 - 15:20 EDT - 所有系统均恢复；

未来措施

此次事故的根本原因是工程师驱动的配置错误。有个用于自动化测试的程序，错误使用了生产证书。因此，我们将会极大减少某些特定行为访问主系统，以确保不再发生类似事故。

正如前文所述，事故的持续时间，主要是受限于恢复数据库时传输数据的网速。虽然这种情况少见，但谁都没法确保不会再这样，所以我们会升级数据库服务器之间的网络连接，同时升级硬件，借以提高恢复速度。我们预计这些改进将在未来几个月内完成。

总结

我们想尽快与您分享这些信息，以便您可以了解事故中断的性质及影响。在未来的日子里，我们将继续评估进一步的防范措施，防止开发人员的错误，继续围绕数据恢复来改进流程，研究在未来发送事故时如何更好地提供实时信息。我们重视服务的可靠性，并致力于提供一个可以让您放心使用的平台。DigitalOcean 全体团队感谢您的理解，对此次事故的影响，我们再次深表歉意。

补充：出现删库事故时，GitLab 和 DigitalOcean 都及时对外公布事故总结。点个👍 ！

觉得本文有收获？请转发分享给更多人

关注「数据库开发」，提升 DB 技能